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Abstract 


We present Coda, the first cryptocurrency protocol that remains decentralized at scale. 
“Scalability” refers to Coda’s ability to handle throughput of thousands of transactions per 
second. “Decentralization” refers to the accessibility of verifying the chain state and synchro- 
nizing as a new user. Synchronizing the chain state with Coda requires receiving less than a 
megabyte of data, allowing devices like smartphones to securely perform transactions indepen- 
dent of how long the protocol has been running or how many transactions have been performed. 
Transactions on Coda can also be verified independent of their complexity, allowing complex 
computations on its blockchain without burdening the network. Coda achieves these features 
without sacrificing either scaling or decentralization through the use of recursive composition 
of zk-SNARKs in a novel architecture that implements a decentralized ledger. The resulting 
consensus protocol is consistent and responsive as long às. at most 1/2 of the mining power is 
malicious. 


1 Introduction 


While cryptocurrencies have achieved notable financial and public recognition, they have had 
practicality problems due to poor scaling and-high resource requirements. Resource efficiency 
is particularly concerning, as,/existing scaling solutions will raise the resource requirements even 
further, harming accessibility and decentralization. 

These problems not only present practicality issues at cryptocurrency’s present level of usage 
(e.g., prohibitively-high transaction, fees, long sync times, high storage requirements for verifi- 
cation), but make scaling cryptocurrency to millions of users to be entirely infeasible without 
sacrificing decentralization. 

We would like a cryptocurrency protocol that achieves the following properties 


1.(Sealable: In order to be used by millions of participants, the system must be capable of 
processing thousands of transactions per second. 


2. Decentralized) In order to minimize centralizing barriers to entry, the protocol must have 


a(Constanticostiofiparticipation The amountjofcomputationalizesources (storage, computa- 
tion, and network usage) @equitedltoljoi and interact with the networkishouldibellowland 


Historically cryptocurrencies have faced a tradeoff between scaling and decentralization [Jor18]. 
As cryptocurrencies scale, their blockchains increase in size, causing increasing burden for par- 
ticipants to verify balances and data on the blockchain. These cryptocurrencies tend towards 
inaccessibility and more centralized validation with usage. 

We present a new protocol, Coda, which overcomes this previous limitation and achieves both 
scaling and decentralization through the use of what we term a/Suecinet blockchain) 

A succinct blockchain is a blockchain for which vérifying the current world state requires only) 
@ constant amount/of data and aconstantamountion time: Concretely, a user of Coda requires 
only around 20 kilobytes and about 10 milliseconds to verify their balance. These requirements are 
independent of the number or complexity of the transactions processed by the blockchain. This 
allows Coda to scale to large numbers of users while staying accessible to those with relatively 
limited computing resources. 


Coda’s succinct blockchain is enabled by fecursive composition of ZESNARKS [BCCT12]. Re- 
cursive composition of SNARKs @iableleonstant=sized proofs of arbitrary, incremental computa> 


GiSHSMThis allows the Coda network to Constructyayproofjofythewvalidityjof blockchaim|/statelthiap 
‘can be updated incrementally as more blocks are added. 


In this paper, we overview the cryptographic preliminaries needed for our succinct blockchain, 
and present the succinct blockchain construction we use in Coda. 


2 Preliminaries 


We begin with some preliminary cryptographic definitions. 


Definition 2.1. @gfunctiony / is called G€gligible if for any polynomial POA ron asuci 
dargana OAN This will often be ASren 


We review the definition of collision-resistant hash functions (CRH) which are used extensively 
in the recursive composition construction. 


Definition 2.2. A @ollision=resistantiliash@fanctiom (CRH) consists of a Probabilisti@ polynomial 
time algorithm Pgen that on input 1^ outputs a circuit h such that for every non-uniform polynomial- 
size adversary A, 


In our protocol, in order @ogensureymaximalyefficieney) of our. SNARK construction, weus® 
cqqpPedersenjhash@funetion [CDv88] [CvP92] [BGG94]. The Pedersen CRH has particularly d6w) 
arithmetic complexity (and so is particularly efficient to verify with a SNARK). 


Definition 2.3 (Pedersen CRH). Fix an elliptieeurve family G = G(1?) and an input length s(A).. 
DherG2Pedersen|CRAGS the CRH given by 


Pgen,(1) 
Gag’y 
(9 --- 9s) s G 


return | (b1,..., bs ofie 


The collision-resistance of the Pedersen CRH reduces to the hardness of finding the discrete 
logarithm of a random element of G (with respect to a random base). For state-of-the-art SNARK 
performance optimizations, please see [HBHW17]. 


Finally, we review the definition of SNARKS for arithmetic constraint systems. For simplicity, 
we define an arithmetic constraint system to simply be @Ulistlefipolynomials\over Fim some) 
variables (a1,...,@r,Y1,---,Ys). 
each variable which causes each polynomial in the system to evaluate to 0. For a € F’,w € F5, | 
we use the notation C(a, w) to indicate that assigning the x; to a and the y; to w is a satisfying 
Definition 2.4. A succinct non-interactive argument of knowledge (SNARK) for F-arithmetic 
(Constraint systems isis a tuple of algorithms (Setup; Prove, Verify) suchthat the following conditions 


are satisfied: 


1. Completeness. 
For any constraint system C and a, w with C(a,w), we have 


Pr [(pk, vk) + Setup(C, 1); m + Prove(pk, a, w); Verify(vk,a,7) = T] =1 
For every (x, W) € Rò 


i) 


| 
| 


ow 


3 Recursive composition of SNARKs for state-transition sys- 
ems 


e 


We now describe at a high level therecursive-composition techniquedescribed variously in [Val08], 
[BCCT13] and [BCTV 14] dorbootstrapping”aipreprocessing SNARK which can only certify exe> 


Instead of phrasing the construction in the language of incrementally verifiable computation as 
in [Val08] or in the language of PCD as is done in [BCCT13] and [BCTV14], we opt to describe 
it im terms of State transition Systems) as it maps more clearly onto the application of producing a 
compact blockchain. PN ae 

non-deterministic? 
Definition 3.1 (State transition system). A state transition system 


@pdatelmayalss “throw an exception” (i.c., ailitolproducela new Statelfor certaim inputs). 
Moreover we ask tha Mana THE poyiz, in the sense that Meir members can berepresentedy 


We now define SNARKs for state transition\systems’ At a high level, we would like poly (\)> 
ize proofs (which are verifiable in poly} time) 


(@ In other words, we would like stiéeiiet certificates Of the existence of Stateatransition sequences 
(joiming two states) The application to. blockchains is the following: we will take our state fo be the) 
(database of accounts (alongwith some metadata needed for correctly validating new blocks) and) 


Definition 3.2 (Incremental SNARKs for state transition systems (informal)). 


Such that) (suppressing parameter generation and passing the parameters to Prove and Verify) 


N = 


ew 


> s h i; 


The@nerenientality is very useful, as it implies the prowing|processicam|bolexecuted limi paialla) 


to compress k state transitions with span (or “wall-clock time”) O(log k). 

Naive recursive composition is extremely expensive. To address this, we use the “@yélé of elliptio 
@urves”) technique (as described in [BCT V14]) ii which twoISNARK constructions (let’s call them 
Tick andyTock) verifyyeachyother, As a first step, let’s define a set of typing rules such that the 
existence of a term 7: 01 tock 02 implies the existence of a sequence of transitions taking 0; to 
c2. The typing rules are as follows: 

oa: 09:4 ¢t:T — update(t,o1) = 02 1: Oo: 7:01 Stick C2 


base wrap 
base(o1, 02,t): 01 Stick 72 wrap(01, 02,7): 01 Tock 72 


oE oib 03: 1:0, Stock O2 T2: O2 Tock 73 

ee merge 

merge(o1, 02, 03, 771-72): 01 Tick 03 

From a term 7: 01 tock 2 we can obtain a sequence of transitions taking a; to a2. Indeed, 

a term of type 01 Tock 02 here is essentially an explicitly parenthesized sequence of transitions 
leading from g1 to oo. 


Now, we will implement each of these deduction rules with a SNARK, such that the proof- 


of-knowledge assumption for each SNARK will correspond to a kind of inversion-lemma for the 
(Corresponding deduction Tile. This will then allow us to apply essentially the same reasoning as 
above to conclude that a SNARK which purportedly witnesses the existence of transitions taking 
` a to 2 in fact implies the knowledge of such transitions. 
We will have 3 SNARKs, one corresponding to each deduction rule. 


1. A Tick-based SNARK for certifying single state transitions; which we'll call the “base” 
SNARK. | 


Input: (The hash of) a tuple (01, 02, y)where o;: © and y is an arbitrary string. 
Statement: There exists t: T such that update(t, 01) = 02. 


2. A Tick-based SNARK for merging two Tock proofs, which we'll call the “merge” SNARK. 
Input: (The hash of) a tuple (or, 03, vk), where o;i: © and vk is a Tock verification key. 


Statement: There exists: “and Tock-proofs 71, 72 such that Verifyy,.,(vk, (01, 02, vk), 771) 
and Verifyy,¢.(vk, (02, 03, vk), T2) 


In plain English, it will prove that (herélexistsia SNARK certifying the existence of transitions 


3. AlTockebasediSNARKwormwrappingyaylickyproof, which we'll call the rap SNARK. Let 


Vkbase, VKmerge be “base” and “merge” verification keys respectively. 
| Input: An arbitrary string z. 


Statement: There exists a Tick proof m and vk € { vkbase, Vkmerge } Such that Verifyi.,(vk, x, 7). 


å K This SNARK merely wraps a Tick SNARK into a Tock SNARK so that another Tick SNARK 


Various tricks are applied in the actual implementation for efficiency’s sake, but for simplicity of 
exposition we omit them here. 
One obtains the following proposition regarding the above proof system. 


Proposition 3.1 (SNARKs for state transition systems, informal). Assume the existence of col- 
lision resistant hash functions and a pair of preprocessing SNARK constructions with linear-time 
knowledge extractors. 

Let (£, T, update) be a state transition system. Then the above construction instantiated with 
those primitives yields a state transition system SNARK for (£, T, update). 


As mentioned, the proof-of-knowledge assumption for each SNARK corresponds to a kind of 
inversion-lemma for the corresponding deduction rule. A full argument (in the language of PCD) 
is provided in [BCTV14]. 


who holds the history of all the transitions? 


4 Succinct blockchains are snarks used for privacy or only compression? 


A succinct blockchain is a blockchain with verification complexity essentially independent of) 
` chain length. Instead of preserving the entire chain, one merely holds onto the current state along 


In fact, it is 
even better: the SNARK certifies the existence of a blockchain explaining a state with Merkle root 


h. Then, usersiwhovaretinterestedtimonly(partionthelstat@ (c.g., their own balance) (@anlbergiven> 
this SNARK along with a small Merkle-path corresponding to root h into the part of the state 


Blockchain verification and extension can be expressed as a state transition system, and thus 
SNARKs for state transition systems as described above enable the construction of succinct 
blockchains. 

We handle the permissioning mechanism (whether it be proof-of-work, proof-of-stake, or some- 
thing else) abstractly. 


Definition 4. (Permission mechanism) A permission mechanism consists of types PermissionState) 
and PermissionProof along with polytime-computable functions 


1. checkPermission: PermissionState x PermissionProof > { T, L } 
2. updatePermission: PermissionState x PermissionProof —> PermissionState. 


Let us give some examples of how this definition can be instantiated. For proof-of-work, the 
permission state would contain several previous difficulty:targets and block-times (from which to 
compute the current difficulty target) and a permission proof would.contain the proof-of-work itself 
along with a new time to update the state with. 

For a Praos-style [DGKR17] proof-of-stake mechanism, the permission state would contain 
the current random seed, the (Merkle root of) the current epoch’s stakes, and some information 
about the previous blocks and block times. A permission-proof would contain a public-key and a 
VREF evaluation proof meeting the difficulty target.corresponding to that public-key and the stakes 
indicated in the permission state. 

This definition omits mention of generating. the permission proofs, dealing only with their 
verification. The following definition of a succinct blockchain will assume some permissioning 
mechanism. We also assume the existencevof a collision-resistant hash function H, and whenever 
we speak of hashes, we are referring to outputs of H. no smart 

We can now describe in more detail the precise transition system giving rise to a succinct contracts? 
blockchain. Our blockchain will maintain consensus on a “ledger”, which is a list of accounts with NO 
Galancés) Users submit “transactions? which areG@istructions to transier balance from one accoum’ transaction 
(another. We discuss the structure of the ledger and transactions in more detail in section A. Sc ripts? 

Instead of containing transactions directly, blocks will include a SNARK proving the existence 

That is, we 
assume a function verifyLedgerProof which given two hashes rı and rg along with a proof 7 returns 
T (computationally) iff there exists a sequence of transactions taking a ledger with Merkle root rı 
to a ledger with Merkle root re. 


Definition 4.2 (Blockchain state). The blockchain’s state type © will be a record consisting of 
1. (previousStateHash: The hash of the previous blockchain state. 
2. (edgerHash:) The Merkle root of the database of accounts with balances. 
3. (PermissionState: A value of type PermissionState. 
Definition 4.3 (Blockchaimtransition). The transition type T will be a record consisting of 
1. permissionProof? A value of type PermissionProof. 


2. dedgerProofiMA SNARK proof. 


3. (hextlédgerHash? The purported hash of the ledger after applying the transactions indicated 
by ledgerProof. 


Finally, we define the update function for a succinct blockchain’s transition system. 
update(s, t) 


assert (checkPermission(permissionState(s), permissionProof(t)) = T); 


assert (verifyLedgerProof(ledgerHash(s), nextLedgerHash(t), ledgerProof(t)) = T); 


return (H(s), nextLedgerHash(t), updatePermission(permissionState(s), permissionProof(t))) 


Simply put, to update a blockchain with a given transition, we check that the transition is per- 
wants to apply to the ledger, and finally we return a new blockchain whose previousStateHash, 


Instantiating the construction of SNARKs for state-transition systems with this update func- 
tion yields a SNARK construction for certifying statements of the form “there exist a sequence 
of appropriately-permissioned transactions which when applied to blockchain-state gı result in 
blockchain-state g2.” We fix an arbitrary “genesis state” oo: © and define a “succinct blockchain” 
(which we may refer to simply as a “blockchain”) as follows. 


Definition 4.4 (Swecinetiblockchaim). In Coda, a blockchain is Blockera stare o Dalons with 
a state-transition SNARK which verifies against the input (09,0). Ie., a SNARK proving the 
existence of a sequence of valid transitions linking the genesis state to o. 


Mode can participate in a succinct blockchain protocol without storing anything except for the 
Strongest blockchain and a full or partial state) If a node has these items, they can be certain that 
the information in whatever state they hold is backed by a blockchain with the strength indicated 


and that balances have been updated only via a sequence of valid transactions contained in that 
blockchain. 


5 Permissioning mechanism and network model 


At a high level, Coda works by simply instantiating the succinct blockchain construction with 
a permissioning mechanism such as Oworoborés*Praos proofofstake protocol[ DGKR17] and the 
same distributed system assumptions. The result would be a succinct proof-of-stake blockchain. 
In practice modes have additional loéal state (beyond that explicitly described in the blockchain) 
i i This process is described in detail in [DGKR17] and is 
essentially unchanged in Coda. 


5.1 Ledger properties 


The succinct blockchain construction instantiated with a particular permissioning-mechanism in- 
herits all of the consensus properties provided by a typical verbose blockchain instantiated with 
the same permissioning-mechanism. 

In particular, assuming Coda is instantiated with a permissioning-mechanism such as Ouoroboros 
Praos, it provides persistence and liveness. 

To properly define permission and liveness, we first define the notion the history of a blockchain. 


Definition 5.1. Gayyoqyogjare)blockchain-states, We say that(ojisitheipredecessorjof a5 (or that 
a2 is the successor of o1) dfA(o7)="previousStateHash(o3)> 


By collision-resistance of H, @achjwalidjblockchain=statelo has!a\computationally=miquelpred) 
cessor whichwedenote|pred(@). This is with exception of the genésis|statelap, which is chosen so 
that it (computationally) as no predecessor.) 


Definition 5.2. Let (ø, 7) be a blockchain, and let k be the (computationally) unique integer such 


that pred” (a) = øo. We define the history of (2,7) to be the set { pred(c), pred(pred(o)),.....pred*(c) }. 


We are now in a position to define the persistence and liveness properties provided by Coda. 
‘Persistence. Suppose an honest node claims at some point that current blockchain is 
Bı and then claims at a later point that the current blockchain is B2. Then with high 
probability B, is in the history of B2. 


Liveness. Suppose all honest nodes in the system attempt to include a given transaction — 
t when updating the ledger. Then with high probability, after a constant amount of time t 
will be used in creating a “ledger proof”, and thus its effect on the ledger will be confirmed 
‘by the network. 
The ledger functionality implemented by Coda has several additional highly desirable properties 


which have not been achieved by any other cryptocurrency. Let A be the mimber of accounts in 
the ledger. 


ledger by downloading an amount of data which has size O(log A) and which requires time- 
(O(log Ate verif® Note that this is asymptotically optimal as O(log A) is the amount of 
data required to even write down an index into a ledger of size A. 


Sustainability. The amount of data stored by any node in the system is constant in the 
qqunberjofitransactionsithathavelbeei processed In particular it is O(A). 


References 


[BCCT12] Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran Tromer. Recursive composi- 
tion and bootstrapping for snarks . . ., 2012. 


[BCCT13] Nir Bitansky, Ran Canetti, Alessandro Chiesa, and.Eran Tromer. Recursive composi- 
tion and bootstrapping for SNARKS and proof-carrying data. pages 111-120, 2013. 


[BCTV14] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Scalable zero 
knowledge via cycles of elliptic curves. pages 276-294, 2014. 


[BGG94] Mihir Bellare, Oded Goldreich, and Shafi Goldwasser. Incremental cryptography: The 
case of hashing and signing. pages.216—233, 1994. 


[CDv838] David Chaum, Ivan Damgård, and\ Jeroen van de Graaf. Multiparty computations 
ensuring privacy of each party’s input and correctness of the result. pages 87-119, 
1988. 


[CvP92] David Chaum, Eugéne.van Heijst, and Birgit Pfitzmann. Cryptographically strong 
undeniable signatures, unconditionally secure for the signer. pages 470—484, 1992. 


[DGKR17| Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros 
praos: An adaptively-secure, semi-synchronous proof-of-stake protocol. Cryptology 
ePrint Archive, Report 2017/573, 2017. http://eprint.iacr.org/2017/573. 


[HBHW17] Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox. Zcash protocol spec- 
ification: Version 2018.0-beta-19 [overwinter+sapling]. https://github.com/zcash/ 
zips/blob/master/protocol/sapling. pdf, 2017. 


[Jor 18] Raul Jordan. How to scale ethereum: Sharding explained. https://medium.com/ 
prysmatic-labs/how-to-scale-ethereum-sharding-explained-ba2e283b7fce, 
2018. 

[Val08] Paul Valiant. Incrementally verifiable computation or proofs of knowledge imply 


time/space efficiency. pages 1-18, 2008. 


Appendix A Ledger and ledger updates 


The succinct blockchain construction described in section 4 assumes the ability to certify the 
existence of transactions taking a ledger in one state to a ledger in another state. Here we describe 
the exact construction in more detail. We assume the existence of a digital signature scheme) 

A (ED will be CLD An GD will be SED 
public-key, an integer representing the account balance, and an integer nonce which functions to 


As described in section 4, ¢he ledger is represented within the blockchain’s transition system 
state as its Merkle Toot This is important for the efficiency of the system as wepresentingythe) 


Ghitire| ledger explicitl yas both prohibitively costi Representing the ledger as its M@#KI@T66t also 
enables the possibility of Gi@esiig the Walidity Of portions of Thelstate (e.g. only one’s own balance) 


without having to see the whole state itself. 


Let us describe how we can “Compress” away transactions again using the transition-system 


| 


€ 


SNARK construction. A ‘transaction’ will be a)record consisting ora senden publickeyra 
“ec” plik, an integer indicating thie no of the transaction an integer none mida AA 
(Signature. We omit discussion of €869 


We instantiate the state-transition SNARK construction to produce 
ments of the form “there exists a sequence of transactions which when applied to the ledger with- 
Merkle root rı yield the ledger with Merkle root r2.” 

The state type will simply consist of a hash (interpreted as the Merkle root of the ledger). A 
transition will simply be a transaction. The (non-deterministic) update function is given by the 


following, where request represents non-determinstic choice and assert aborts the computation 
if the given condition is not true. 


let update t s = 
let { signature; body = { sender; receiver; amount; nonce } } = t; 
Signature.assert_verifies signature sender t.body; 
let s?’ = 
find_and_modify s sender (fun account -> 
assert (account.balance >= amount); 
assert (account.nonce = nonce); 
return { account with balance = account.balance.- amount; nonce = nonce + 1 }); 
let s’’ = 
find_and_modify s’ receiver (fun account -> 
return { account with balance = account.balance + amount }); 
return s’? 
where 
find_and_modify s public_key f = 
request account : Account; 
assert (account.public_key = public_key) ; 
request auth_path : List (Book * Hash); 
Merkle_tree.assert_membership s account auth_path; 


request s? : Merkle root; 
Merkle_tree.assert_membership s’ (f account) auth_path; 
return s’ 


It is important to reiterate that theyinereniental{mature|of ithe transition-system! SNARK icon=> 
` struction enables one to compose individual transactions along a binary tree. This means that a 
` sequence of k transactions can be compressed into a single SNARK in span C - logk (for some 

constant C). 

What this means is that even though the requirement that transactions be verified with a 
SNARK incurs a computational overhead, it does not incur a “wall-clock time” overhead. To be 
specific, if k transactions per second are sent to the system, over s seconds, we will need to SNARK 

_sk transactions. This will take time Clog(sk) = C log k + C log s, which for large enough s is less” 
¢han®) Thus the time required to SNARK the transactions will asymptotically be exceeded by 
the time taken to produce the transactions, allowing the system to function at any throughput 
assuming sufficient parallelism. 


